\section{SCRUM}

\textit{I dette afsnit forklarer vi hvordan vi har arbejdet med SCRUM i undervisningen, for derefter at overføre de lærte elementer til arbejdet med fjerde semester projektet. Vi viser vores brug af SCRUM principperne samt illustrerer forløbet med andre planlægningsværktøjer.}

\subsection{Første møde med SCRUM gennem Lego øvelse}

Efter arbejdet med LEGO øvelsen, fik vi mod på at prøve SCRUM som planlægningsmetode til at styre tidsestimeringen i vores andetårsprojekt. I LEGO øvelsen fik vi et indblik i, hvordan vi kunne analysere, estimere og uddelegere de forskellige arbejdsopgaver (tasks) vi skulle igennem, for at projektet kunne tage form.
\\
\\
Vi startede med at dele opgaven op i tre sprints, hvert sprint foregik på følgende måde; I analysen havde vi fra start af en overordnet product backlog (Figur \ref{dia.scrumsprint}), hvori de forskellige segmenter til hhv. hus, å/bro og strandbar var defineret. Vi valgte derefter at lave forskellige tasks, som vi skulle nå i sprintet, for at bygge det givne segment. For at kunne estimere hver task bedst mulig, benyttede vi planning poker. Dette bliver beskrevet senere i afsnittet.

\begin{figure}[H]
\centering
\includegraphics[scale=0.7]{pictures/diagram_scrum.jpg}
\caption{Illustration af SCRUM sprint, inkl. product-/sprint backlog.}
\label{dia.scrumsprint}
\end{figure}

\subsection{Projektet}

De ting vi lærte under lego øvelsen, valgte vi at arbejde videre med i vores projekt. Det var derfor også naturligt for os at anvende samme fremgangsmåde som under legoøvelsen. Vi startede med at udvælge de tasks, fra vores allerede konstruerede produkt backlog, som skulle laves i sprintet. Herefter analyserede vi hver task, hvorefter vi estimerede med planning poker. Da vi havde estimeret alle tasks, blev de delt ligeligt mellem gruppens medlemmer, og skrevet ind i vores virtuelle SCRUM board.

\subsection{Estimering og planlægning}

For at kunne lave en realistisk tidshorisont af vores arbejdsopgaver samt overholde deadlines overfor SMU, ville vi bruge planning poker \citep[s.56]{CadleAndYeaters}. Hver person i gruppen estimerede her, ud fra sin egen subjektive vurdering, hvor lang tid en task ville tage. Ved argumentation i plenum kunne vi komme frem til et realistisk og velovervejet estimat af arbejdsopgavernes varighed.
\\
\\
Da vi ikke havde mulighed for at slæbe rundt på et SCRUM board, besluttede vi os for at lave et virtuelt board (Figur \ref{dia.scrumboard}) i Google Docs i stedet. Det gav os mulighed for at samle alt SCRUM materiale ét sted, og alle i gruppen havde derfor mulighed for at for at tilgå boardet døgnet rundt.
\begin{figure}[H]
\centering
\includegraphics[scale=0.6]{pictures/PlanningTable.png}
\caption{Illustrerer tasks til venstre og hvilken status de har.
\\\textbf{In Progress:} Fortæller at der arbejdes på tasken.
\\\textbf{Done:} Er en betegnelse for at den ansvarlige mener han/hun er færdig med opgaven.
\\\textbf{Review:} Er når en anden fra gruppen reviewer den ansvarliges arbejde.
\\\textbf{Done Done:} Beskriver at opgaven er færdig. }
\label{dia.scrumboard}
\end{figure}

Da vi gerne ville have et generelt billede af tidshorisonten for samarbejdet med SMU, lavede vi et Gantt diagram (Figur \ref{dia.gant}), som illustrede i hvilke perioder vi arbejdede med de forskellige dele af projektet.
\begin{figure}[H]
\centering
\includegraphics[scale=0.6]{pictures/GanttDiagramWeeks.jpg}
\caption{Illustrerer tasks i forløbet og i hvilke perioder vi arbejder med de forskellige på.}
\label{dia.gant}
\end{figure}
Vi vidste på forhånd at SMU havde en deadline i start april, derfor skulle vores implementation af de services vi skulle udbyde til dem, være færdige til den tid. Vi kunne fra start af planlægge introduktionen med dem, hvilke forventninger de havde til projektet samt hvornår vi skulle mødes næste gang. Vi planlagde derudover en dag med retrospektiv af samarbejdet i slutningen af samarbejdsforløbet. Her ville idéen være at samle op på ting såsom; forståelsesvanskeligheder samt kulturelle forskelle eller andre problemer som undervejs var opstået.

\subsection{SCRUM møder}

Vi havde SCRUM-møder et par gange om ugen, hvor fremgang og eventuelle problemer med arbejdsopgaverne blev taget op. Dermed kunne resten af gruppen komme med løsningsforslag og på bedst mulig vis hjælpe personen videre, som beskrevet i \citep{SchwaberBeedle} - “Ongoing inspections provide the information necessary to empirically determine what to do next”.

\subsection{Rollefordeling}

Vi havde under vores projekt, en SCRUM master, som også fungerede som udvikler. Det skyldtes at vi kun var fem i gruppen, og derfor ikke havde ressourcer til blot at have en som kun var SCRUM master. SCRUM masterens opgave var at skabe overblik, holde gruppen opdateret og hjælpe til med konkrete løsninger, hvis der opstod problemer. I henhold til teorien, består et team derudover af en product owner, som fungerer som bindeled mellem kunde og SCRUM team, heruden være med til at bestemme hvilke task der skal prioriteres højest. Da vi i vores projekt, var vores egen kunde, besluttede vi at være fælles om product owner rollen, så alle havde lige stor indflydelse på hvad der skulle prioriteres \citep[s.166-167]{ChonMChapter6} 